Teams identified that a new template version had been created and remained in the platform's holding/CS validation state, which halted automatic sending. The change was approved in CS, the template was started and returned to automatic sending, and queued/ongoing sends resumed so recipients received the expected emails and suffixes. For regional sign-off issues, templates were edited to remove the outdated MENA paragraph and re-enabled to use the standard UK sign-off and confirmation flow; multiple templates were updated to restore consistent behavior.

Investigations found multiple root causes where template conditional logic, mapping errors and registration-phase precedence produced incorrect or missing content. Key findings and what was done:

Across incidents, troubleshooting relied on SR.Qual_Code, FINANCIAL_PRODUCT, MF.Receipt_Date, registration flags and LIBF/purchase fields to reproduce faults. Resolutions comprised manual remediation and reissue of affected emails, fixes to template selection and paragraph-filtering logic, corrections to date and import mappings, and membership/template updates; immediate fixes were deployed where required and remaining hardening work was placed on the backlog.

Template-level and scheduling faults were resolved by disabling or correcting templates and by registering or stopping affected overnight/bulk jobs as appropriate (for example the EVENTS template was stopped from auto-sending on request). Stopped or failed scheduler/orchestration processes (Rundeck REST routes, LetterWriter, EMAILCNN/EMAILINV and hosting servers) were restarted and hosting issues repaired, which released queued messages and allowed backlog processing to complete. Where attachment/receipt generation jobs had stalled they were restarted so queued EMAILCNN messages attached receipts and were dispatched; a developer defect preventing SPS payment receipts was fixed and deployed, restoring receipt delivery. Integration faults affecting registration/Brightspace and Transfer2Epos transfers were corrected and stalled transfers were rerun or reset, allowing downstream confirmations and provisioning to resume. Bulk-extract and selection logic that had been including inappropriate records (for example extracts relying solely on receipt_date and therefore including closed/cancelled registrations) was amended to exclude closed/cancelled records; a number of nightly bulk jobs that were no longer required were stopped. DistributionServices records were checked for missing despatch files; missing files were retrieved and attached to requesters as needed. Investigations confirmed that EMAILCNN/receipt behaviour sent copies to both the student and the invoice‑payer when a receipt existed, explaining bouncebacks from invalid invoice addresses. Individual missing confirmations or invitations were manually resent by support (session and correlation IDs were recorded in tickets). STARTA bulk-history entries that were unsent were deleted where appropriate to prevent unintended future sends, and individual recipients were excluded from LetterWriter/SPS renewal/non‑renewal runs where requested. Internal service‑desk allocation notifications were restored after users were re-added as watchers in the ticketing system. Timing and scheduling gaps (results or registrations posted after nightly extracts) were recorded for late‑results considerations. Where duplicate sends were traced to application behaviour (for example the timetable 'Teilnehmer informieren' producing one identical email per recipient) the issue was escalated to the vendor (Simovative) for investigation. In cases where mass-mailings affected other sends, queues and sending status were checked and the interactions were documented (a CARE instance showed 'Versand wird vorbereitet' while affected sends were investigated). All fixes and support actions were recorded in tickets to allow manual resends or further follow-up where necessary.

Investigations repeatedly identified mismatched sender/envelope identities, unverified or blocked sender addresses, legacy allowed‑senders entries, missing hard‑bounce/abuse contacts, MX1 sender‑rewrite behaviour changes during cutover, transient SMTP connection/greeting failures, and incorrect/misspelled From/envelope addresses as root causes. Resolutions and diagnostic findings included:

These actions eliminated 554 relay rejections and sender‑selection failures in applications in reported cases, restored inbound mailbox acceptance and ticket conversion for permitted senders, preserved sender‑identity behaviour across MX1→SES migrations, revealed legacy SMTP clients still using MX1, resolved individual outbound‑send blocks caused by unverified accounts, and avoided distributor throttling during planned large sends. One Workday case was observed with intermittent sender‑address switching and log entries of 'got bad greeting from SMTP host'; that incident was monitored for recurrence while other systemic fixes were applied elsewhere.

Support triaged mailbox lifecycle, routing and identity incidents after verifying mailbox ownership and noting applicable data‑retention requirements. Mailbox creation, renaming, scheduled deactivation or deletion proceeded only after ownership and retention checks; where a mailbox could not remain deactivated it was deleted and removed from clients. Investigations frequently found licensed-but-deactivated or duplicate accounts still receiving mail; these were resolved by correcting licensing/account state, consolidating or removing the mailbox, and updating records. Forwarding and alias work preserved forwarding chains, implemented bulk forwards from supplied lists, enabled forwarding that retained copies in the original mailbox when requested, replaced invalid/expired forwarding targets, and recorded time‑limited external forwards only after privacy/datenschutz review and written consent. Publicly exposed or outdated addresses on websites or intranets were identified and corrected or removed; persistent senders were client‑side blocked when necessary. For mailbox access problems support reactivated, unlocked, or reset passwords for short documented windows, delivered credentials to a verified private email or via the organisation’s secure app, informed users about self‑service options (for example Okta self‑service password reset), and where necessary disabled and re‑registered a user’s 2FA/MFA to restore access. Outgoing identity problems were resolved by correcting SMTP sender addresses and display names and re‑adding the intended identity; some changes required coordination with external IT teams. SMTP/send‑user provisioning required collected metadata (sender email, primary/secondary contacts, expected send rates, attachment sizes, cost centre and bounce/suppression contacts); administrators created the SMTP user in the chosen outbound service, recorded account details, stored credentials in 1Password and delivered credentials via the organisation’s secure app or a verified channel. Where no internal outbound relay existed AWS SES was used as an example outbound relay (email-smtp.eu-central-1.amazonaws.com; ports 25, 587 and 2587 supported, TLS required; port 587 recommended). Legacy relays (for example mx1.iubh.de) were also used and relay‑specific parameters such as port 587 and observed send‑rate constraints were noted (example observed: 50 connections per 60 seconds). Service/service‑account mailboxes were sometimes provisioned under an internal or alternate domain (for example s.@iu.org) when the requested external domain was unavailable; credentials were provided to the requester and the decision recorded. When support lacked administrative access to the requested external domain they escalated to the domain owner or advised stakeholders to obtain domain administration access (or accept an alternate internal domain). For application or third‑party duplicate‑address problems support recommended aliasing (plus‑addressing) as an alternative to creating separate mailboxes and demonstrated registration of +tag variants. Integration and platform‑specific cases were treated as routing/integration work and escalated to the product or integration team with per‑address routing details noted; some product teams required a formal User Story or project request before production changes proceeded. Automation and mail‑to‑ticket examples (Jira Automation, Salesforce Email‑to‑Case, OTRS, Freshdesk, Twilio) were escalated with observed symptoms and routing details; in several cases forwarding/automation rules or mail handler settings were found to block or discard messages from external/non‑organization senders, causing messages to be missing from both the target system and the source mailbox. OTRS and similar failures were resolved by repairing mailbox authentication or mailfetch paths (for example replacing invalid tokens or fixing IMAP/POP connectivity); once retrieval was restored platforms processed accumulated messages via polling/import jobs, which could produce gradual imports or one‑off ticket spikes. To prevent duplicate tickets or residual ingestion during migrations, support adjusted routing rules (for example stopping ingest when the target address only appeared in CC), updated queue configuration, disabled obsolete queues and removed permissions to move tickets into deprecated queues. Contingent‑worker or external accounts were provisioned only after a formal New Contingent Worker Account submission and approver in the IT Service Portal. In cases where original messages were still retrievable, support sometimes resolved user complaints by resending the missing message content to the mailbox owner. Device‑generated mail (for example scan‑to‑email from multifunction printers) appeared in the ticket set as a distinct symptom: in at least one case sends from an MFP to a specific recipient stopped while sending to a colleague still worked; support logged suggested troubleshooting steps (including verifying the device address‑book entry and the recipient mailbox/alias state) but no resolution was recorded. Duplicate or stale mailbox addresses sometimes required deletion or conversion to an alias and, in some cases, were only resolved after local clarification with the user.

Investigators separated distinct root causes and applied targeted remediations. For third‑party newsletter tooling (JungleMail) the immediate cause in several incidents was exhausted monthly or quarterly send quotas; business units contacted the vendor and the vendor issued temporary quota extensions in at least one case and larger annual mailing quotas were purchased as a long‑term fix. Support also added regular JungleMail quota monitoring every 2–3 days to detect approaching limits before scheduled sends. For SMTP/SES sending and migration paths (MX1 SMTP / evasys → AWS SES) the risk was provider send‑rate and throughput limits given observed peaks (~1,350 mails/min, daily volumes up to ~180,420); resolution required requesting increased SES sending quotas/throughput, coordinating timing for account cutover, and collecting account metadata (contact persons, planned volumes, attachment expectations, cost centre, hard‑bounce contact) to avoid throttling. Separately, investigators encountered recipient‑level delivery issues on vendor‑managed platforms (Dotdigital) where internal support did not have access to vendor preferences or delivery logs; those cases were referred to the marketing team/Dotdigital administrators for vendor‑side investigation of subscription status, suppression lists, mailing‑list inclusion, and delivery/bounce logs. Across incidents the observable symptoms were quota warning notifications, capacity/throttling or silent non‑delivery rather than explicit bounce codes; monitoring of monthly/quarterly quota usage and provider send‑rate limits, and escalating vendor‑access or marketing‑owner investigations for recipient‑level suppressions, were established as operational mitigations.

Affected Salesforce Lightning email templates that contained hidden/Word-origin formatting produced visible encoding artifacts (question marks, HTML entities, or garbled characters) in the compose/reply editor and in outgoing messages. Where the artifact persisted, support duplicated the problematic template, cleared/deleted the duplicate’s template text to remove the hidden Word formatting, saved the cleaned duplicate, performed test sends, and replaced the original template; this removed the encoding artifacts for the reporting users. In other incidents the malformed display corrected itself without changes; support verified the template/rendering after reopening before applying the template cleanup.

Support inspected bounce notification headers and the original message content to identify the exact recipient address, the SMTP error returned (for example 'User Unknown'), and the server that generated the bounce. Resolutions were recorded by root cause: - Typographical errors: the incorrect address was corrected at the authoritative source and the message was resent; corrected deliveries completed successfully. - Internal system data mismatches: inconsistent email records across systems (for example Care, Epos, myCampus, Oasis) were reconciled by identifying and updating the authoritative record in the source system so downstream systems received the update via existing synchronization; mail delivery errors then ceased. - External forwarding/provider failures: bounces traced to third‑party forwards or remote providers (for example rediffmail, electric.net) were attributable to the remote provider generating the bounce; IT could not remediate the remote provider, so support provided reconciled contact records and alternative contact methods or asked the recipient to resolve their forwarding with the provider. - Test/placeholder addresses: bounces traced to intentionally created test or placeholder addresses submitted via websites or registrations were confirmed as expected testing; no mail‑system configuration changes were required. - Messages not sent by internal systems: some bounces related to messages claiming to be invoices or communications for internal teams but which did not appear in sending logs or CRM/invoicing records (for example Oasis showed no related account or invoice). In those cases support confirmed the messages did not originate from the expected internal service, recorded the discrepancy, and engaged the appropriate product or registration owners to reconcile contact records and inform business teams. Throughout, support validated recipients against internal records, analysed SMTP headers to determine the true sending/relay hosts, engaged product/registration teams where authoritative records or website data were implicated, and documented whether the cause was a local typo, an internal data‑sync/address mismatch, an external provider/forwarding failure, intentional test data, or a message that did not originate from internal systems.

Investigation confirmed that the institution had claimed the @iu.org domain in Apple Business Manager, which triggered Apple’s domain‑claim notification that personal Apple IDs using that domain would be disallowed after the indicated date. The case was closed after admins and the user acknowledged the domain claim behavior; the user changed the Apple ID contact address to a non‑corporate email (or used a separate personal Apple ID) and was informed that purchases/data were unaffected by the notification. The outcome documented that this behavior was an expected effect of Apple Business Manager domain claims rather than an email delivery or mailbox fault.

Security and mail operations checked message logs and filtering systems and found no blocks or rejections; the mail server was confirmed to accept 12 MB attachments. Because no mailserver rejection or filtering event was present, the team recommended using the SAFE App / SAFE Portal (iu-it.org) for transferring large contract files as an alternative delivery method. The sender later confirmed that the recipient had received the contracts, and no server reconfiguration was required.

Template-level permissions were updated to grant Edit access on EMAILCNN and EMAILINV to the four named users. After the permission changes, all affected users were able to access and edit the two templates.

The requested header/banner images were added to the Letterwriter asset library and made available for email and letter templates; the oversized image was resized to match the other assets before publication so all four images were usable in Letterwriter.

Investigations identified two classes of failures that blocked email ingestion into OTRS. In one case, specialists diagnosed and repaired a temporary fault in the OTRS mail-retrieval process that had prevented the system from pulling messages into mailboxes; after the retrieval functionality was repaired the queued messages were processed and the backlog delivered to OTRS. In a separate incident inbound mail routing was misconfigured: specific addresses (for example accommodation-bh@iubh.de) were not forwarded to the central OTRS address (otrs@iubh.ie), likely after a license/reset event; the missing forwarding was restored and affected messages began flowing into OTRS, creating tickets. Users did not report explicit SMTP error codes in either scenario. Normal mail delivery to the helpdesk resumed after the respective retrieval fix and forwarding restoration and the backlog was cleared.

Investigations confirmed the repeated messages were legitimate system-generated notifications produced by internal automations. Three distinct patterns and outcomes were observed: (1) Cascade workflow reminders: notifications persisted while an outstanding task remained in the user's Cascade workflow and ceased after the end user logged into Cascade and completed the task or after the People Team cleared the workflow/task on the user's behalf. (2) LMS notification loop: a faulty automation in the Learning Hub (referred to as a 'welcome-mail-sending-loop') caused repeated mandatory-training notifications even after course completion; the Learning Hub automation was corrected/disabled by the team and duplicate mails stopped. (3) Grade-notification duplicates: automated grade-publication emails were triggered by entries in the CARE/grade database (Notendatenbank) and sent from noreply-fs-service@iu.org for each grade entry (including recognitions), producing multiple over-triggered notices; investigators traced the messages through CARE, the grade database exports, and related Salesforce/Simovative records and documented investigation steps, but no configuration change or final remediation was recorded in the ticket. In all confirmed cases, duplicate emails stopped when the underlying automation was fixed or the outstanding workflow/task was completed or cleared, or when the responsible team applied a corrective change; where no fix was documented, further remediation was required by the owning application team.

Postfix per-destination delivery throttling was applied to mitigate remote-MX concurrent-connection limits that caused mass delivery failures. The Postfix main configuration (/etc/postfix/main.cf) was adjusted: default_destination_rate_delay was increased (initially from 1s and finally to 4s), which limited deliveries so roughly one message was sent to the same destination every four seconds. This change prevented remote servers from returning repeated "421 Too many concurrent SMTP connections" and "451 Recipient is busy" errors and stopped messages from vanishing and later bouncing due to exceeded retry windows. Incidents also showed unrelated recipient-side defers such as "452 4.2.2" (over quota), which were separate causes for individual deferred deliveries. In one case suppliers for the sending application and the recipient gateway were engaged while logs were analysed to confirm the remote MX connection-limiting behaviour.

The user switched to Firefox and was then able to select and apply layout templates in CARE successfully. The reported problem was resolved by using Firefox, indicating a browser-compatibility issue with template selection in other browsers.

IT reviewed the reports, confirmed the Bewerberportal was outside central IT responsibility, and closed the ticket after directing the requester to the portal's support channel (IU Meldeportal / Jira Service Management). The incident was handled by advising contact with the application-portal owner rather than applying changes in the IT-controlled mail system.

Support investigated each incident and verified there were no changes or errors on the internal mail infrastructure. For verification-email cases the external service confirmed the message was sent at the logged timestamp and the user later received the email without intervention. For inbound-to-service cases (monday.com) support confirmed the user’s account membership and that the non-delivery report originated from the external provider; the user later regained the ability to send to the board without internal changes. Tickets were closed after confirming delivery or restored functionality; support recommended contacting the external service’s support team if the issue recurred.

A parameterised recognition template and scheduled send workflow were implemented. The template populated unit name, qualification name and assessment-type fields from Brightspace/reporting data; a maintained whitelist excluded ended/withdrawn assessment elements after stakeholder sign-off. A daily scheduled job (configured to run one day after official results-release time) queried results ≥90% across all PE qualifications; deduplication logic aggregated multiple qualifying results for the same student into a single email containing a tabular summary of each qualifying assessment. Stakeholder-agreed assessment-element lists and the one-day post-release send offset resolved the open questions and prevented duplicate sends.